% lo que hicimos y por qué

\section{Discusi\'on}

En esta secci\'on se pretende dar una explicaci\'on de las distintas 
partes de este trabajo pr\'actico, comentando las decisiones que 
tomamos y el por qu\'e y las alternativas encontradas.

\subsection{Sobre las stories}

En primera instancia, ten\'iamos user stories que hablaban de cosas 
que quer\'ia el equipo (como equipo queremos) y al product 
owner s\'olo le hab\'iamos asignado querer la respuesta final (que se 
le aplique ``publicable /no publicable'' a un comentario seg\'un 
corresponda). \\


Despu\'es nos dimos cuenta del inconveniente de este enfoque, el 
product owner no deber\'ia pedir en realidad algo tan b\'asico, por lo 
cual decidimos reescribir las stories. Esta vez las dividimos de otra 
forma, tratando de asignarle al product owner cosas que pod\'ia llegar
a querer. \\


Esto permiti\'o eliminar user stories existentes que estaban partidas
(la parte de \-de\-sa\-rro\-llo la hac\'ia el equipo y el Product 
owner s\'olo ped\'ia solo la asignaci\'on de un label de 
publicaci\'on), y unirlas en una sola separada en tasks. \\


Se eliminaron users stories que hablaban de aspectos muy generales como
``detectar comentarios con todos los dem\'as tipos de insultos''.
Este tipo de stories, en una siguiente iteraci\'on, no iban a poder 
ser incorporadas al sprint por ser demasiado grandes. Esto se deb\'ia a
que no estaban bien particionadas, teniendo, l\'ogicamente una 
estimaci\'on muy alta de Story Points.

Se solucion\'o dividiendo este tipo de stories en otras que 
hicieran referencia a cada tipo de insulto que el product owner 
requer\'ia detectar, por separado.\\


Al principio, pens\'abamos que tokenizar el texto iba a ser facil, pero
al realizarlo, nos dimos cuenta que el tema los acentos no lo 
hab\'iamos tenido en cuenta. Esto es, palabras como canci\'on y cancion
consideramos que deber\'ian ser tomadas como iguales a efectos de saber 
si es o no un insulto.\\

Tuvimos que modificar las tareas de esta story para que el cambio se 
viera reflejado. 
La estimaci\'on ya no pod\'ia cambiarse por estar dentro del sprint
esa story, con lo cual qued\'o poco consistente seg\'un las tareas 
que esta story conlleva.\\


Para la story de detectar literales, el tiempo de la task de detectar
el literal en sí es muy alto porque tiene incorporado el desarrollo
de todo el sistema en s\'i que maneja la recepci\'on de comentarios, 
y procesamiento, para luego hacer una comparaci\'on de cada token
contra los literales de insultos.

\subsection{Sobre el diseño}

Para realizar el diseño, tuvimos varias etapas, en las que fuimos 
refinando cada vez m\'as, tomando decisiones y eligiendo entre 
alternativas. Tambi\'en pas\'o que cambi\'abamos cosas ya hechas 
cuando nos d\'abamos cuenta que no estaban tan bien como pens\'abamos 
en un principio. \\

En primera instancia pensamos en poner el tokenizer antes del 
moderador porque supon\'iamos que ibamos a tokenizar cualquier
comentario antes de pas\'arselo al moderador.\\


Al continuar con el diseño, nos dimos cuenta de que hab\'ia diferentes 
estrategias a emplear de a acuerdo a la configuraci\'on actual de 
tipos de insultos a detectar.\\


Para los insultos partidos, nos result\'o mejor aplanar todo el 
comentario y buscar insultos literales como substrings en ese string 
aplanado. 
Para los insultos separados por letras conven\'ia aplanar las 
palabras con longitud 1 (esto es, si dos palabras seguidas tienen 
longitud 1, se juntan) y ver si se detecta algun insulto literal.
Para los dem\'as tipos de insultos, se toma cada palabra como token y 
se analiza por separado cada token hasta encontrar (o no) un 
insulto del tipo buscado.\\


Este cambio se vi\'o reflejado en el diagrama de diseño, 
ahora la estrategia conoce al tokenizador y tokeniza segun una configuración dada.\\


En un momento, exist\'ian buscadores, adem\'as de detectorse, 
en el diagrama que actualmente se llama detectores 
(antes era buscadores). Nos dimos cuenta que 
estaban de intermediarios, y no cumpl\'ian ninguna funci\'on por
si mismos, m\'as que dejar la responsabilidad de todo totalmente 
al detector. Lo hab\'iamos agregado porque el nombre nos pareci\'o
que reflejaba lo que representaba, pero lo terminamos sacando para
simplificar el diagrama.\\

Tambi\'en nos dimos cuenta de que los detectores no ten\'ian 
una relaci\'on de conocimiento con el lector del archivo de
literales, y necesitaban tenerla para pasarle los literales 
al aplicador de reglas para que supiera cuando terminar de aplicar
reglas (al llegar a alg\'un literal de la lista). \\

Los detectores conocen al lector que lee tanto las reglas, como
el archivo con los literales, pero s\'olo le van a pedir leer 
los literales antes de mandarle el comentario junto con la lista 
de literales, al aplicador de reglas para que aplique hasta 
llegar a alg\'un literal de la lista.\\

Tambi\'en el ejecutor de estrategias, lo unico que hac\'ia 
era ejecutar una estrategia que le pasaban por par\'ametro.
Es decir, que no hac\'ia falta que conociera al tokenizador 
(y dem\'as), sino que bastaba con que ejecutara la estrategia.
La estrategia es la que conoce a todos estos cosos objetos que
aplana y tokenizan, etc; y que llama a los que corresponden 
seg\'un de qu\'e estrategia se trate.

\subsection{Sobre la implementaci\'on}

En esta parte no surgieron tantas alternativas, la mayor parte de las 
decisiones ya hab\'ian sido tomadas antes, al diseñar. Lo que s\'i
ocurri\'o fue que tuvimos que rever el diseño porque al momento de 
realizar la implementaci\'on en c\'odigo, surgieron a la vista 
aspectos no considerados. \\

Separamos entre interfaz y controlador de html, tratando de seguir
un modelo de MVC. \\

Como python no tiene el concepto de clase abstracta o interfaz, 
lo que se hace es. Para solucionar esto, lo que se hizo fue,
en las funciones que deber\'ian ser abstractas, poner
\texttt{raise NotImplementedError(texto)}.
Por ejemplo, en detector.py, la funci\'on aplicarReglasPara es
abtracta, por lo que se realiz\'o lo dicho.
















